ci: pin exact Xcode 26.3 on macOS jobs (definitive libz.tbd fix)#758
Conversation
Even with SDKROOT pinned, build-macos failed because the macOS jobs ran on runner images with different *newest* Xcodes: the ogre/assimp producers sometimes resolved Xcode 26.5 (newest on their image) and cached an SDK whose Codec_Assimp/ogre CMake export hardcodes 26.5's libz.tbd path, while the consumer (26.3) couldn't link it. "sort -V | tail -1" is non-deterministic across images. Pin a SPECIFIC Xcode (26.3) that's present on all current macos-latest images, falling back to newest only if absent — so producers and consumer always agree on the SDK. Bump MACOS_CACHE_VERSION → xc263pin to discard the assimp+ogre caches that still carry a 26.5 path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe PR bumps the ChangesXcode 26.3 pin and cache invalidation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/deploy.yml (1)
1577-1590: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDeduplicate the pinned Xcode path across the three macOS jobs.
Line 1585, Line 1664, and Line 1752 repeat the same hardcoded pin. Centralizing it in workflow
envreduces drift risk when the pin changes again.♻️ Suggested refactor
env: BUILD_TYPE: Release AQT_VERSION: '==3.3.*' QT_VERSION: '6.9.3' + PINNED_XCODE_DEV_DIR: '/Applications/Xcode_26.3.app/Contents/Developer' ASSIMP_VERSION: '6.0.4'- PIN="/Applications/Xcode_26.3.app/Contents/Developer" + PIN="$PINNED_XCODE_DEV_DIR" if [ -d "$PIN" ]; then DEV="$PIN" else DEV=$(ls -d /Applications/Xcode_*.app/Contents/Developer 2>/dev/null | sort -V | tail -1) fiAlso applies to: 1662-1669, 1750-1757
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy.yml around lines 1577 - 1590, The hardcoded Xcode pin "Xcode_26.3.app" is repeated in three separate macOS job sections at lines 1585, 1664, and 1752 in the workflow file. To reduce drift risk when this pin needs to be updated in the future, extract this value into a single environment variable defined at the top-level workflow `env` section, and then reference that variable (using ${{ env.VARIABLE_NAME }}) in all three job locations where the PIN variable is currently set.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 1577-1590: The hardcoded Xcode pin "Xcode_26.3.app" is repeated in
three separate macOS job sections at lines 1585, 1664, and 1752 in the workflow
file. To reduce drift risk when this pin needs to be updated in the future,
extract this value into a single environment variable defined at the top-level
workflow `env` section, and then reference that variable (using ${{
env.VARIABLE_NAME }}) in all three job locations where the PIN variable is
currently set.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 46921318-a1df-49e5-9fac-a079e6f6037a
📒 Files selected for processing (1)
.github/workflows/deploy.yml
|
1 participant
Definitive fix for the recurring macOS
libz.tbddeploy failure.Root cause (peeled back over several attempts): the macOS jobs run on runner images whose newest Xcode differs (one job resolved 26.5, another 26.3). The OGRE/Assimp SDKs bake the active SDK's absolute
libz.tbdpath into their CMake export, so a producer that built under 26.5 cached an SDK the 26.3 consumer can't link (No rule to make target '.../Xcode_26.5/...libz.tbd').sort -V | tail -1(newest) is non-deterministic across images; SDKROOT pinning helped the app's own ZLIB but the cachedCodec_Assimp/ogre dylibs still carried the producer's path.Fix: pin a SPECIFIC Xcode (26.3, present on all current
macos-latestimages) on all three macOS jobs, falling back to newest only if absent — so producers and consumer always agree on the SDK. BumpMACOS_CACHE_VERSION→xc263pinto discard the assimp+ogre caches that still carry a 26.5 path. (Keeps the SDKROOT pin + self-heal OGRE rebuild from the prior fixes as belt-and-suspenders.)Needed to complete the 3.9.1 macOS deploy (Windows + Linux already published; macOS artifact + Homebrew cask pending).
🤖 Generated with Claude Code
Summary by CodeRabbit